Floppyshop 2/Floppyshop - 2.zip/Floppyshop - 2.iso/diskmags/0022-3.564/dmg-0085/250.txt

Text File | 1997-04-16 | 16KB | 368 lines

=========================================================================

INFO-ATARI16 Digest         Fri, 23 Feb 90       Volume 90 : Issue  250

Today's Topics:
                       All Black Screen Savers
                           Editor Wanted!!!
                             Mouse events
                      overscan resistent editor
                               poolfix3
                              Questions
                                RateHD
                        Real Time Programming
             Uniterm/Terminal Emulators Question (2 msgs)
----------------------------------------------------------------------

Date: 23 Feb 90 15:40:00 GMT
From: apollo![e-mail]  (Steve Rehrauer)
Subject: All Black Screen Savers
Message-ID: <[e-mail]>

In article <[e-mail]> [e-mail]
 (Roland Rambau) writes:
>[e-mail] (Bill White) writes:
>->Out of curiosity, wouldn't it be simpler just to set all the colors to zero?
>
>This does not work in monochrome mode. You can't set both colors to black
>- the systems probably recognizes only 1 bit of the color table ( standard
>vs. inverted ).

Note that, from what has been said here about it, the TT's 640x400
'monochrome' display mode really does pay attention to both color 0
and color 1.  (I believe the mode is actually called 'duochrome' on
the TT, ugg.)  Such a blanker would work on the TT, at least for the
3 ST resolutions.
--
>>"Aaiiyeeee!  Death from above!"<< | Steve Rehrauer, [e-mail]
   "Flee, lest we be trod upon!"    | The Apollo System Division of H.P.

------------------------------

Date: 23 Feb 90 18:40:28 GMT
From: zaphod.mps.ohio-state.edu!math.lsa.umich.edu![e-mail]
 (Howard Chu)
Subject: Editor Wanted!!!
Message-ID: <[e-mail]>

In article <[e-mail]> [e-mail]
 ("Bernd_Esser") writes:
>A few days ago, i installed Overscan in my Mega. Unfortunately i had to
>recognize that none of my editors can work with the higher resolution.
>My question is: Is there somebody who kwows an editor that will work in
>overscan mode( i am using a b/w monitor)?

The only editor I use is the micro-emacs implemented in Gulam. It works
fine in overscan mode. Note, if you "set nrows 50" in monochrome, Gulam
will be confused at first. Exit it and restart it, and it'll get the screen
dimensions from LineA and all will be well. (86 columns by 60 rows.)
(I avoid this hassle by having a small AUTO program that sets the 8-line
font at boot-up. Then I don't need the Gulam "set nrows" command, and
TOS uses the 8-line font without hassles...)

--
  -- Howard Chu @ University of Michigan

------------------------------

Date: 23 Feb 90 16:39:15 GMT
From: [e-mail]  (Paul Purdom)
Subject: Mouse events
Message-ID: <[e-mail]>

I am using Get_Event routine from Personal Pascal, and I am having a little
trouble with mouse button events. I don't get them when the mouse is on
(roughly) the top 10 lines of the screen. (This is where a menu would
normally go if I were using menu.) I get mouse events from the rest of the
screen just fine. If someone knows what my problem is, can they mail me some
information. (I am pwp.iuvax.cs.indiana.edu). If you know how to solve the
problem using C instead of Pascal I can probably still use the information.

Thanks, Paul Purdom.

------------------------------

Date: Fri, 23 Feb 90 12:57+0100
From: [e-mail]
Subject: overscan resistent editor
Message-ID: <900223115734.631672@DMZRZU71-UNI-MAINZ--GERMANY>

Bernd Esser writes:

>A few days ago, i installed Overscan in my Mega. Unfortunately i had to
>recognize that none of my editors can work with the higher resolution.
>My question is: Is there somebody who kwows an editor that will work in
>overscan mode( i am using a b/w monitor)?

I am using GNOME, a MicroEmacs Clone by Moshe Braner (well, in fact an
extended version of the program). It is small (some 50 k), fast, has
builtin help
but lacks substitute and query replace (can be worked around by a
macro). I find working with it more convenient than with MicroEmacs 3.9.
Invoke the program as
          gnome -c 30 -r 86 file.ext
to use the extended screen of 688x480 pixels. The original program is on
various file servers. I got my copy from listserv@canada01, which
recently has moved to a different location.

Michael Ritzert
[e-mail]

PS: my extensions include german help and error messages, second macro
    buffer (nesting of one macro into the other possible), storing of
    keyboard macros on disk, improved bufferd disk-io, subsitute and
    query-replace commands. Improved buffer printing is being worked on.


------------------------------

Date: 23 Feb 90 16:31:00 GMT
From: cs.yale.edu![e-mail]  (Michael Fischer)
Subject: poolfix3
Message-ID: <[e-mail]>

In article <[e-mail]> [e-mail] (Jim Hurley) writes:
>[e-mail] (Allan Pratt) writes:
>
>>[e-mail] writes:
>
>>>[We have a program which dies; poolfix3 improves it a little.]
>>>Question to Allan or Ken:
>>>      Shall I install folder100 in addition [to poolfix3]?
>
>>You should certainly use foldr100.  Poolfix3 only fixes a bug in
>>the code which manages GEMDOS's internal memory.  You can still
>>run OUT of memory there, and FOLDR100.PRG adds more.  A program
>>which uses Malloc() a lot, or has lots of open files at the same
>>time, can use up all this memory.
>
>Could you please elaborate? I thought TOS 1.4 fixed the
>folder problem. Should one *always* use FOLDRXXX?
>
>Actually, although I've heard a lot about this bug, I've never
>read a consistent description of the problem.

Here's my understanding of things: TOS needs memory for various
internal things which it takes from a memory pool of FIXED SIZE.  When
memory is no longer needed, it is returned to the pool for later
reuse.  FOLDRXXX allows you to increase the size of the pool, and
POOLFIX3.PRG fixes a TOS 1.4 bug in the management of that memory.
Even with both programs, it is possible to run out of memory,
especially if you do a lot of Malloc's, but obviously, the bigger the
pool, the less likely you are to run out.

TOS 1.0 and 1.2 used the memory less wisely and had varous bugs in the
management of the pool that could cause the machine to crash.  In
particular, it failed to check properly when the pool was exhausted,
so when too many folders or too many Malloc's used up the pool, weird
things would start happening.  The so-called "40-folder" limit was
just an empirical observation that users who had at most 40 folders on
their disks were unlikely to exhaust memory.  Thus, as long as one had
at most 40 folders, the problem would not usually be encountered.  By
increasing the size of the pool, FOLDRXXX allowed more folders to be
used.

Allan Pratt put a lot of effort into cleaning this up in TOS 1.4.
[Thanks, Allan!]  You are now much less likely to run out of memory,
and crashes shouldn't happen.  In particular, inactive folders no
longer use memory, so you can have a large number of folders on your
disk without needing to increase the size of the pool.  However, you
still can run out of internal memory and you may well need to use
FOLDRXXX to increase the size.  If you do run out, the system stops
with an "out of internal memory" message and suggests that you
increase the size of the pool.
==================================================
| Michael Fischer                                |
|    Arpanet:    <[e-mail]>   |
|    Bitnet:     <[e-mail]> |
|    UUCP:       <[e-mail]>     |
==================================================

------------------------------

Date: 23 Feb 90 18:31:32 GMT
From: uflorida!beach.cis.ufl.edu![e-mail]  (Christopher Roth)
Subject: Questions
Message-ID: <[e-mail]>

Hi there...

I am looking for a program to control the drive speed for a 5.25 inch
drive on an Atari ST that works with Tos 1.4.  Is there any out there
that someone can suggest?

Has anyone heard word of anything beyond Masterlink 1.1?

My local atari store cannot get ahold of Spectre GCR.  He says all the
distributors are out.  I live in Gainesvill, Florida.  Can someone
name a distributor that has Specter GCR or a store that has it?  Dave? Anyone?

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*     Christoper Roth                         *  "Machines have no
*     InterNet  :  [e-mail]      *   Conscience..."
=-=-=-=-=-=-=-=-=-=-=-=-=-Post No Bills-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

------------------------------

Date: Fri, 23 Feb 90 13:11+0100
From: [e-mail]
Subject: RateHD
Message-ID: <900223121113.363135@DMZRZU71-UNI-MAINZ--GERMANY>

Chris Ridd wrote:

>I tried the RateHD a day or so ago
>...
>time was only about 36ms!  Has DLII (the defragger used) done something
>unexpected to my drive, or has RateHD gone doolally?

RateHD is buggy. The results for the access time can be considered only
a *rough* estimate. I found out that there is even a dependence on the
partition size.

Michael Ritzert
[e-mail]

------------------------------

Date: 23 Feb 90 18:51:59 GMT
From: logicon.arpa!trantor.harris-atd.com!trantor![e-mail]  (polivka al
 60047)
Subject: Real Time Programming
Message-ID: <[e-mail]>

I want to write a program for the ST that involves acurate timing and
therefore needs access to the internal clock or timers in the ST.  I
would like a few suggestions.

In particular, I want to continuously read events comming in via the
midi-in port and note the time at which they were received to a
(user-selectable) accuracy of about 1 to 10 milliseconds.

I will also need to be able send out messages over the midi-out port
by reading them from a file that contains all of the messages to be
sent along with the time at which each message is to be sent out (with
similar timing accuracy).

My questions are:

1. What language/compilers are recommended for doing this sort of thing?

 1a.  i.e. Do certain compilers provide commands or routines for
      easily getting access to Atari's internal clock and/or timers?

 1b.  How does the efficiency (in terms of memory and CPU utilization)
      for such real time routines compare between the various
      candidates (particularly in comparison with code compiled with
      Personal Pascal or Megamax C)?

2. Does the "Personal Pascal" compiler in particular allow such real
   time programming (I already own it and am familiar with it)?

 2a.  If so, how (what commands/routines need to be used for accessing
      the clock and/or timers)?

 2b.  There is a "clock" command in Personal Pascal but it only has 2
      second accuracy to my understanding.

3. Does anyone have any sample source code for this sort of thing that
   they'd be willing to share?

Those of you familiar with midi may realize that I am trying to
understand how to write the real time aspects of a "sequencer"
program for the ST.

Thanks,
Al
--

------------------------------------------------------------------------
Al Polivka                           arpa: [e-mail]
Mail Stop 102-4858                 usenet: uunet!x102a!apolivka
Harris Corporation                  phone: [phone]
Government Aerospace Systems Div.    Bldg: 102 Room: 3433
P.O. Box 94000
Melbourne, FL 32902
------------------------------------------------------------------------

------------------------------

Date: 23 Feb 90 18:34:19 GMT
From:
 pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!hyc@tut
 .cis.ohio-state.edu  (Howard Chu)
Subject: Uniterm/Terminal Emulators Question
Message-ID: <[e-mail]>

In article <[e-mail]> [e-mail]
 writes:
>     Could someone tell me if there is a more recent version of Uniterm than
>2.0e? If there is, does it have full 132 column capability instead of the
>previous 128? If not, is there a good commercial or PD program that will serve
>as a full 132 column VT200 emulator? I really need the full 132 capability.
>Thanks in advance to anyone kind enough to respond.

The latest version I've heard of is 2.0e011. The latest version I have, and
have put up on terminator, is 2.0e002. (If someone out there has 2.0e011,
will you please contact me? Huh? Please, pretty please???) None of these do
full 132 columns, scrolling or otherwise.

It'd be painful to write horizontal scrolling routines for this thing.

I installed Overscan in my machine, and then patched Uniterm to be resolution
independent. (I patched 2.0e002, the only one available to me.) (Actually,
"patching" is an understatement for all the changes I made...) My current
version is several kilobytes shorter, and 25% faster than the distributed
versions. With overscan active I get 137 columns and 60 (59) text rows on a
monochrome screen, and 144 columns and 35 (34) text rows on a color screen.
I've also fixed the redial bug, the screen redrawing when switching from
<view history> to <wide screen> modes, and a few other minor glitches.

If you want more than 128 columns of text out of Uniterm, stick Overscan
into your machine, or buy a Moniterm or similar (large) display...
--
  -- Howard Chu @ University of Michigan

------------------------------

Date: 23 Feb 90 18:34:19 GMT
From:
 pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!hyc@tut
 .cis.ohio-state.edu  (Howard Chu)
Subject: Uniterm/Terminal Emulators Question
Message-ID: <[e-mail]>

In article <[e-mail]> [e-mail]
 writes:
>     Could someone tell me if there is a more recent version of Uniterm than
>2.0e? If there is, does it have full 132 column capability instead of the
>previous 128? If not, is there a good commercial or PD program that will serve
>as a full 132 column VT200 emulator? I really need the full 132 capability.
>Thanks in advance to anyone kind enough to respond.

The latest version I've heard of is 2.0e011. The latest version I have, and
have put up on terminator, is 2.0e002. (If someone out there has 2.0e011,
will you please contact me? Huh? Please, pretty please???) None of these do
full 132 columns, scrolling or otherwise.

It'd be painful to write horizontal scrolling routines for this thing.

I installed Overscan in my machine, and then patched Uniterm to be resolution
independent. (I patched 2.0e002, the only one available to me.) (Actually,
"patching" is an understatement for all the changes I made...) My current
version is several kilobytes shorter, and 25% faster than the distributed
versions. With overscan active I get 137 columns and 60 (59) text rows on a
monochrome screen, and 144 columns and 35 (34) text rows on a color screen.
I've also fixed the redial bug, the screen redrawing when switching from
<view history> to <wide screen> modes, and a few other minor glitches.

If you want more than 128 columns of text out of Uniterm, stick Overscan
into your machine, or buy a Moniterm or similar (large) display...
--
  -- Howard Chu @ University of Michigan

------------------------------

End of INFO-ATARI16 Digest V90 Issue #250
*****************************************